Simulado Comentado para Concurso: Analista em Computação – PROCERGS 2025

Foco: Programação de Sistemas na tecnologia Microsoft

Estudar por meio de questões comentadas é uma das melhores formas de fixar conteúdo para concursos de TI. Neste artigo, você terá 10 questões comentadas, com a resposta correta destacada e explicações detalhadas, tanto do porquê a alternativa está correta quanto do motivo das demais estarem erradas.

No universo do desenvolvimento de software moderno, a adoção de metodologias ágeis revolucionou não apenas a forma de criar software, mas também como testá-lo. Os testes ágeis emergiram como uma adaptação natural dos princípios do Manifesto Ágil para a área de garantia de qualidade, trazendo novos conceitos e desafios. Neste artigo, exploraremos profundamente os fundamentos dos testes ágeis, testes de componente e testes de integração, respondendo a questões-chave que todo profissional de TI deve dominar.

Questão Teste de Componente (Unidade)

Enunciado: O teste de componente (também conhecido como teste de unidade/unitário ou módulo) é um teste de caixa branca que se concentra em componentes que são testáveis separadamente. Assinale a alternativa que NÃO é um exemplo de produto de trabalho que pode ser usada como base de teste para testes de componentes.

Alternativas:

A) Documento de especificação.

B) Projeto detalhado.

C) Código.

D) Modelo de dados.

E) Programação de componentes.

Análise e Resposta:

O teste de componente (unitário) é caixa branca e foca no código e nos artefatos técnicos ligados a ele. Pergunta:

Qual NÃO é base de teste para teste de componentes?

Analisando as alternativas à luz do gabarito:

A) Documento de especificação.
Correta (gabarito).
Explicação: a especificação de requisitos é usada normalmente em testes de sistema e aceitação, não em testes de componente. O unitário foca no código e nos artefatos técnicos que descrevem a implementação, não em requisitos de negócio.

B) Projeto detalhado.
Pode ser base, porque contém diagramas de classes, fluxos lógicos, contratos de métodos etc.

C) Código.
É a principal base de teste unitário, já que é um teste caixa branca.

D) Modelo de dados.
Também pode servir de base, pois as estruturas de dados influenciam diretamente o comportamento dos componentes.

E) Programação de componentes.
Apesar de soar estranho, aqui a banca tratou como um produto de trabalho (o resultado da programação — ou seja, o código escrito). Não é a atividade em si, mas o que dela resulta.

Resposta correta (segundo o gabarito): A) Documento de especificação.

🔎 Por que as outras não são a resposta

B, C, D e E → Todos são artefatos técnicos diretamente ligados à implementação, usados como base no nível de teste de componente (unitário).
A → Documento de especificação é alto nível, serve como base para testes de sistema/aceitação, mas não para unitário.

Em resumo:

Teste de componente = foco em código, projeto técnico e modelos internos.
Teste de sistema/aceitação = foco em especificação e requisitos.

Teste de Componente: Os Alicerces da Qualidade do Código

A Base de Tudo

No mundo dos testes de software, o Teste de Componente (ou Teste de Unidade) é a fundação sobre a qual toda a estratégia de qualidade é construída. Sendo um teste de caixa branca (que avalia a estrutura interna e o funcionamento do código), seu objetivo é verificar a menor parte testável de um software, como uma função, classe ou método, de forma isolada. Este artigo explora os produtos de trabalho que servem de base para estes testes e identifica qual elemento não se encaixa nessa categoria.

Produtos de Trabalho que Baseiam os Testes de Componente

Os testes de componente não são criados no vácuo. Eles se baseiam em artefatos específicos do processo de desenvolvimento que definem o "o quê" e o "como" do componente deve funcionar.

A) Documento de especificação.

O que é: Em contextos ágeis, isso se traduz principalmente nos Critérios de Aceitação de uma história de usuário. Eles descrevem, em linguagem de negócio, as condições que o componente deve satisfazer para ser considerado pronto.

Como serve de base: Os critérios de aceitação são transformados em casos de teste unitários. Por exemplo, o critério "O usuário deve receber uma mensagem de erro ao inserir um CPF inválido" direciona a criação de testes para a função validaCPF() com diversas entradas incorretas.

B) Projeto detalhado.

O que é: Diagramas ou descrições de baixo nível que detalham a estrutura interna do componente, como diagramas de classe UML, diagramas de sequência ou decisões de design interno.

Como serve de base: Este artefato guia o teste dos caminhos lógicos internos. Se o projeto detalha que um método possui um loop for com uma condição if interna, os testes de unidade devem ser criados para cobrir todos os caminhos possíveis (executar o loop, não executar, entrar no if, não entrar no if), garantindo uma cobertura de código abrangente.

C) Código.

O que é: O código-fonte real do componente que está sendo desenvolvido.

Como serve de base: Esta é a base mais direta. A análise estática do código (linting) é uma forma de teste. Além disso, para escrever testes unitários eficazes, o tester/desenvolvedor precisa analisar o código para entender suas entradas, saídas,分支 (ramos) e dependências, a fim de mocká-las adequadamente.

D) Modelo de dados.

O que é: A definição da estrutura de dados que o componente irá manipular, como diagramas entidade-relacionamento (ER) ou esquemas de banco de dados.

Como serve de base: Se um componente é responsável por salvar um usuário no banco de dados, o teste de unidade deve verificar se o objeto de domínio é corretamente mapeado para a estrutura de dados definida no modelo. Testes podem validar a integridade dos dados antes de uma operação de salvamento.

E) Programação de componentes. (A Alternativa que NÃO é uma Base)

Por que NÃO é um produto de trabalho: A "programação de componentes" refere-se à atividade ou ao processo de escrever o código dos componentes. Não é um artefato ou documento resultante desse processo (como o próprio código, o modelo de dados ou o projeto detalhado são).

A Confusão: É um termo meta, que descreve a ação de criar o que será testado, e não uma base para criar os testes. Os testes de componente são baseados nos resultados dessa programação (o código, o design), e não na atividade em si.

Conclusão

Escrever testes de componente eficazes requer uma compreensão clara de diversos artefatos técnicos, desde a especificação de negócio até o design interno e a estrutura de dados. Entender que a "programação de componentes" é a atividade que gera esses artefatos, e não um deles, é crucial para uma estratégia de teste de unidade bem fundamentada e eficaz, que assegura a robustez de cada bloco de construção do sistema.

O que é teste Unitário?

O teste unitário (ou teste de unidade/componente) é um tipo de teste de software que se concentra em verificar a menor parte testável de uma aplicação, conhecida como unidade. Essa unidade pode ser uma função, um método, uma classe ou um módulo.

O principal objetivo do teste unitário é garantir que cada parte do código-fonte, isoladamente, se comporte como o esperado. Ele é feito geralmente pelo próprio desenvolvedor durante a fase de codificação.

Características principais do teste unitário:

Foco no isolamento: O teste é executado em uma única unidade, sem dependências de outras partes do sistema, como bancos de dados, APIs ou serviços externos. Para isso, são usados "doubles de teste" (como mocks, stubs ou fakes) para simular essas dependências.
Teste de caixa branca: O testador (neste caso, o desenvolvedor) tem conhecimento do código-fonte. Isso permite que ele crie testes que cobrem diferentes caminhos de execução, verificando a lógica interna do código, condições e loops.
Automação: Os testes unitários são quase sempre automatizados. Isso permite que eles sejam executados de forma rápida e repetida, garantindo que novas alterações no código não quebrem funcionalidades existentes (processo conhecido como regressão).

Definição Simples

É a prática de testar as menores partes testáveis de um software, chamadas de unidades, de forma isolada das demais. O objetivo é verificar se cada unidade individualmente se comporta conforme o esperado.

O que é uma "Unidade"?

Uma "unidade" é geralmente:

Uma função ou método em programação procedural ou orientada a objetos.

Uma classe inteira.

Em alguns casos, um módulo ou componente muito pequeno e coeso.

A chave é que a unidade é a menor parte do código que pode ser logicamente isolada para teste.

Características Principais do Teste Unitário

Isolamento (Mocking/Stubbing): Este é o conceito mais importante. A unidade testada não deve depender de bancos de dados, serviços web, sistemas de arquivos ou outras classes e módulos. Se houver dependências, elas são substituídas por versões falsas (mocks ou stubs) que simulam o comportamento esperado. Isso garante que uma falha no teste seja um problema na unidade testada, e não em uma de suas dependências.

Rápido: Por serem isolados e testarem pequenos pedaços de código, os testes unitários executam extremamente rápido. Uma suíte com milhares de testes deve levar apenas alguns segundos ou minutos para ser executada.

Automático: São executados automaticamente por ferramentas (frameworks de teste), sem necessidade de intervenção manual.

Repetível: O resultado de um teste unitário deve ser consistente. Ele não deve falhar em uma execução e passar em outra sem que o código tenha sido alterado.

Objetivos e Benefícios

Encontrar Bugs Precocemente: Bugs são encontrados logo durante o desenvolvimento, tornando sua correção mais fácil e barata.
Facilitar Mudanças (Refactoring): Ao fazer uma alteração no código, você pode executar os testes unitários para ter confiança de que não quebrou nenhuma funcionalidade existente. Eles funcionam como uma "rede de segurança".
Servir como Documentação: Um bom teste unitário mostra, na prática, como uma unidade de código deve ser usada e qual comportamento é esperado dela.
Melhorar o Design: Escrever código testável força o desenvolvedor a criar um design melhor, com classes e funções mais focadas, coesas e com acoplamento baixo.

Exemplo Prático

Suponha uma função simples em Python que calcula o imposto sobre um produto:

python

def calcular_imposto(preco, aliquota):

if preco < 0:

raise ValueError("O preço não pode ser negativo.")

return preco * (aliquota / 100)

Os testes unitários para essa função seriam:

python

import pytest

def test_calcular_imposto_valor_positivo():

# Prepara (Arrange)

preco = 100

aliquota = 10

# Executa (Act)

resultado = calcular_imposto(preco, aliquota)

# Verifica (Assert)

assert resultado == 10

def test_calcular_imposto_valor_negativo():

# Prepara (Arrange)

preco = -50

aliquota = 10

# Verifica se a exceção é levantada (Assert)

with pytest.raises(ValueError):

calcular_imposto(preco, aliquota) # Executa (Act)

Perceba que os testes:

São isolados: não dependem de nada além da função calcular_imposto.

São rápidos e automáticos.

Testam um único cenário cada (um caminho feliz e um de erro).

Quem os Executa?

Geralmente são os próprios desenvolvedores que escrevem os testes unitários para o código que estão produzindo, muitas vezes usando a metodologia TDD (Test-Driven Development), onde o teste é escrito antes do código que irá implementar a funcionalidade.

Frameworks Populares

Java: JUnit, TestNG

Python: unittest, pytest

JavaScript/Node.js: Jest, Mocha, Jasmine

C#: NUnit, xUnit.net

PHP: PHPUnit

Em resumo, o teste unitário é a primeira e mais crucial linha de defesa para garantir a qualidade do código e a correta funcionalidade de um software. Ao encontrar e corrigir defeitos no nível da unidade, o custo de reparo é muito menor e o desenvolvimento se torna mais rápido e confiável.

Questão Teste de Integração

O teste de integração se concentra nas interações entre componentes ou sistemas. Quanto maior o escopo da integração, _____ pode se tornar mais difícil e levar a um aumento do risco e a um tempo adicional para a solução de problemas.

A) efetuar os testes de integração com o cliente final

B) isolar os defeitos em um componente ou sistema específico

C) cadastrar um defeito para uma integração

D) encontrar um defeito nos testes

E) gerar os resultados dos testes de integração

Resposta correta: B) isolar os defeitos em um componente ou sistema específico.

Explicação:

Em testes de integração, vários módulos interagem.
Quanto mais componentes, mais difícil saber em qual parte está o defeito.
O tempo de diagnóstico aumenta, elevando riscos.

Análise e Resposta:

A alternativa correta é B) "isolar os defeitos em um componente ou sistema específico".

Quando o escopo de integração aumenta:

Mais componentes/sistemas estão envolvidos na interação

As dependências entre eles se tornam mais complexas

Quando um defeito é detectado, identificar sua origem exata torna-se significativamente mais desafiador

Isso aumenta o tempo necessário para diagnóstico e correção

Eleva o risco de problemas não detectados chegarem a fases posteriores do desenvolvimento

Este desafio de isolamento de defeitos é uma das principais razões pelas quais equipes ágeis preferem:

Integrações frequentes e em pequenos incrementos

Testes de integração automatizados

Estratégias de integração contínua

Técnicas como "feature toggles" para gerenciar integrações complexas

Teste de Integração: O Desafio de Conectar as Peças do Quebra-Cabeça

Conectando os Pontos

Enquanto os testes de componente verificam unidades isoladas de código, o Teste de Integração avança um passo crucial: ele foca nas interações e interfaces entre esses componentes ou sistemas integrados. Seu objetivo é detectar defeitos nas conexões, como incompatibilidades de comunicação, erros no tratamento de dados passados entre módulos ou suposições incorretas sobre o comportamento de um componente dependente. Este artigo examina o principal desafio que surge à medida que o escopo dessas integrações cresce.

O Dilema do Escopo Ampliado

A afirmação do enunciado é clara: "Quanto maior o escopo da integração, _____ pode se tornar mais difícil". Vamos analisar as alternativas no contexto desse desafio de complexidade crescente.

A) Efetuar os testes de integração com o cliente final

Análise: Envolver o cliente final (UAT) geralmente acontece após os testes de integração internos. A dificuldade de executar testes com o cliente está mais relacionada à logística e disponibilidade do que diretamente ao escopo técnico da integração.

B) Isolar os defeitos em um componente ou sistema específico. (A Alternativa Correta)

Análise: Esta é a resposta correta e representa um dos maiores desafios nos testes de integração.

Por quê? Em uma integração de grande escopo, com dezenas de componentes interconectados, uma falha em uma funcionalidade pode ter sua origem em qualquer ponto da cadeia. O sintoma (ex: "o relatório não é gerado") pode ser causado por um defeito no Componente A, no Componente B, na interface entre eles, na rede ou no banco de dados.

Consequência: A dificuldade de isolar a raiz do defeito consome um tempo significativo de diagnóstico (debugging), aumenta o risco de não se encontrar a causa verdadeira e pode levar a "correções" que apenas tratam o sintoma em um local, enquanto o defeito real persiste em outro.

C) Cadastrar um defeito para uma integração

Análise: O ato de cadastrar um defeito em uma ferramenta de gestão (como Jira) é um processo administrativo. Sua dificuldade não é afetada pelo escopo técnico da integração, mas sim pela clareza com que o defeito é documentado.

D) Encontrar um defeito nos testes

Análise: Paradoxalmente, em um sistema mal integrado, encontrar a existência de um defeito pode ser fácil (o sistema falha de forma óbvia). A verdadeira dificuldade, como explicado na alternativa B, não é encontrar que há um problema, mas sim isolar onde e por que ele está ocorrendo.

E) Gerar os resultados dos testes de integração

Análise: Ferramentas modernas de automação e CI/CD (como Jenkins, Azure DevOps) automatizam a execução de testes e a geração de relatórios de resultados. Esta é uma tarefa amplamente automatizada, cuja complexidade não escala significativamente com o escopo da integração.

Conclusão

O teste de integração é um pilar crítico para a qualidade do software, garantindo que as partes individuais, que podem funcionar perfeitamente em isolamento, trabalhem harmoniosamente em conjunto. No entanto, seu sucesso depende de uma estratégia consciente: integrar e testar em pequenos incrementos e com uma boa suíte de testes automatizados. Essa abordagem controla a complexidade, mitigando o principal risco de qualquer integração ampla: a tarefa hercúlea de isolar a origem exata de um defeito em um emaranhado de dependências.

Questão Estratégias de Teste para Mobile

Uma estratégia de teste fornece uma descrição geral do processo de teste, comumente no nível do produto ou organizacional. Existem tipos comuns de estratégias para abordagem de testes. Para a abordagem de testes em aplicações em dispositivos móveis, há uma estratégia de teste que é uma das mais utilizadas, pois esse tipo de estratégia de teste depende do uso sistemático de um conjunto predefinido de testes ou condições de teste, como uma taxonomia de tipos comuns ou prováveis de falhas, uma lista de características de qualidade importantes ou padrões de aparência e comportamento de aplicativos móveis ou páginas da web da empresa. Qual estratégia é essa?

A) Metódica.

B) Analítica.

C) Contra regressão.

D) Reativa.

E) Compatível com processo.

Resposta correta: A) Metódica.

Explicação:

Metódica → baseada em checklists e padrões já conhecidos.
Analítica → baseada em risco.
Contra regressão → foca em não quebrar o que já funcionava.
Reativa → adapta-se durante o teste.
Compatível com processo → segue padrões do processo adotado.

Questão Análise de Risco em Testes

Pergunta: A análise de risco em projetos de teste de software, embora tenha suas características próprias, deve seguir as mesmas regras e metodologias aplicadas a projetos de software em geral. O risco é um dos elementos mais importantes a ser trabalhado no momento de se elaborar o projeto de teste de um software. Portanto, ao preparar o plano de teste e fazer a análise de riscos e definir a cobertura de testes, devemos levar em conta alguns elementos, que são:

A) Se existe risco evidente ou não e se há necessidade de mapear o mesmo no plano.

B) Probabilidade de ocorrência do risco e o impacto e a perda associada a esse risco.

C) Riscos são mapeados pelo analista na especificação e não são considerados no plano de teste.

D) Mapear a probabilidade de ocorrência do risco e, se menor que 40%, não considerar.

E) Avaliar o impacto do risco levantado pelo gerente de projetos na execução de testes.

Resposta correta: B) Probabilidade de ocorrência do risco e o impacto e a perda associada a esse risco.

Explicação:

Em análise de risco, sempre avaliamos probabilidade e impacto.
Outras alternativas simplificam ou reduzem a abrangência da análise.

Questão OWASP e Ameaças Web

As aplicações web estão sendo grandes alvos de ataques de segurança. Assim, testes de segurança devem ser realizados amplamente em uma aplicação web. A metodologia Owasp Testing Guide aborda assuntos sobre pré-requisitos de segurança em aplicações web, princípios de técnicas de testes. Seguindo esses parâmetros gerais levantados pelo guia Owasp, tem-se as principais ameaças voltadas às aplicações web. Assinale a alternativa que NÃO configura uma ameaça às aplicações web.

A) Injeção de Código.

B) Cross-Site Scripting (XSS).

C) Tratamento de erros no código.

D) Referência Insegura e Direta a Objetos.

E) Falta de Função para Controle de Nível de Acesso.

Pergunta: Qual NÃO é ameaça a aplicações web?

A) Injeção de Código.
B) Cross-Site Scripting (XSS).
C) Tratamento de erros no código.
D) Referência Insegura a Objetos.
E) Falta de Controle de Acesso.

Resposta correta: C) Tratamento de erros no código.

Explicação:

OWASP Top 10 → lista ameaças reais.
Injeção, XSS, IDOR, Falta de controle de acesso → estão no OWASP.
Tratamento de erros é uma boa prática, mas não ameaça por si só.

Questão Modelo V

Pergunta: Referente ao modelo V de teste de software, composto por Verificação e Validação e que integra o processo de teste ao longo do processo de desenvolvimento, implementando o princípio de testar do início, é correto afirmar que:

A) Desenvolvimento orientando a comportamentos (BDD) não utiliza o Modelo V.

B) Modelo V utiliza desenvolvimento orientado a testes (TDD) como base do processo.

C) Semelhante ao modelo cascata, o modelo V associa as técnicas de teste com as fases.

D) Modelo V inclui níveis de teste associados a cada fase de desenvolvimento correspondente.

E) Os testes de aceitação são os primeiros a serem contemplados no modelo V nas duas vértices.

Resposta correta: D) Modelo V inclui níveis de teste associados a cada fase de desenvolvimento correspondente.

Explicação:

Modelo V = evolução do cascata.
Cada fase de desenvolvimento tem sua fase de teste correspondente.
Exemplo: análise de requisitos ↔ testes de aceitação.

Questão Regra 10 de Myers

Pergunta: Em 1979, Glenford Myers afirmava haver uma importância que as atividades de testes fossem executadas de forma paralela a todas as outras fases de desenvolvimento de software criando a regra 10 de Myers, que estabelece uma importante questão para os defeitos. Essa regra implica em:

A) À medida em que os erros vão migrando nas fases de desenvolvimento, o custo de correção aumenta em 10 vezes mais.

B) Ao tratar erros durante o processo de desenvolvimento, estabelece 10 boas práticas a se seguir.

C) A cada 10 bugs encontrados, é efetuada uma medida a ser considerada nas métricas dos relatórios de gestão.

D) Estabelece 10 fases no ciclo de vida dos bugs, iniciando no cadastro e acompanhamento até sua solução.

E) A regra número 10 de Myers era que o defeito deve ser priorizado assim que detectado até sua correção.

Resposta correta: A) À medida em que os erros vão migrando nas fases de desenvolvimento, o custo de correção aumenta em 10 vezes mais.

Explicação:

Quanto mais tarde um defeito é detectado, mais caro fica corrigi-lo.
Exemplo: erro em requisitos custa muito mais quando encontrado em produção.

Questão Estratégias de Teste

Pergunta: Para implantar testes de software em projetos, existem várias estratégias que podemos adotar. As estratégias de teste servem para nos guiar para o objetivo de encontrar e eliminar o máximo possível de bugs e desvios de implementação. Para a escolha da estratégia, há quatro abordagens: duas em relação ao tempo em que os testes iniciam e duas em relação às fontes de informação disponíveis. Assinale a alternativa que NÃO se trata de uma abordagem de testes.

A) Preventiva.
B) Analítica.
C) Estruturada.
D) Reativa.
E) Heurística.

Resposta correta: C) Estruturada.

Explicação:

Quatro abordagens de teste:
- Preventiva (antes do código).
- Reativa (durante/ após).
- Analítica (baseada em risco).
- Heurística (baseada em experiência).
Estruturada não faz parte.

Questão Conceitos de Testes Ágeis

Enunciado: Com o avanço do desenvolvimento de software baseado em processos de desenvolvimento ágil, também houve adaptações em outros processos que acompanham o desenvolvimento, como o processo de teste em que um novo modelo de trabalho chamado Testes Ágeis surgiu. Nesse modelo, foram adaptados alguns conceitos do Manifesto Ágil para os testes. Assinale a alternativa INCORRETA quanto à definição dos conceitos de testes ágeis.

Alternativas:

A) Testar em cada etapa ao invés de testar no final.

B) Prevenir bugs ao invés de encontrar bugs.

C) Testar o entendimento ao invés de checar funcionalidades.

D) Construir o melhor sistema ao invés de quebrar o sistema.

E) Os Testers são responsáveis pela qualidade.

Análise e Resposta:

A alternativa E) "Os Testers são responsáveis pela qualidade" é a INCORRETA no contexto dos testes ágeis.

Nos métodos ágeis, a qualidade é uma responsabilidade compartilhada por toda a equipe, não apenas dos testadores. Este é um dos princípios fundamentais que diferenciam a abordagem ágil dos métodos tradicionais:

Desenvolvedores são responsáveis por escrever código testável e criar testes unitários

Product Owners garantem que os requisitos estejam claros e testáveis

Testers atuam como facilitadores da qualidade, ajudando a equipe a pensar criticamente sobre os critérios de aceitação

A equipe multidisciplinar trabalha junta para garantir a qualidade em todas as etapas

As outras alternativas representam conceitos corretos dos testes ágeis:

A) Reflete a prática de testes contínuos ao longo do desenvolvimento (shift-left testing)

B) Representa a mentalidade preventiva em vez de apenas detectiva

C) Significa que testes validam o entendimento do valor de negócio, não apenas a conformidade com especificações

D) Indica a mudança de mentalidade de "quebrar o código" para ajudar a construir o melhor produto possível

Desvendando os Princípios dos Testes Ágeis: O que é Verdade e o que é Mito?

A Evolução do Teste na Era Ágil

A ascensão das metodologias ágil e DevOps transformou radicalmente o ciclo de vida do desenvolvimento de software (SDLC). Nesse novo contexto, os processos de teste, antes often visto como uma fase final e isolada, tiveram que se reinventar completamente. Surgiu assim o conceito de Testes Ágeis, uma adaptação dos valores e princípios do Manifesto Ágil para a garantia da qualidade. Este artigo desmistifica os conceitos fundamentais dessa abordagem, identificando um equívoco comum sobre onde reside a responsabilidade pela qualidade.

Análise Detalhada de Cada Conceito

A) Testar em cada etapa ao invés de testar no final.

Elementos Citados: Teste em cada etapa, Teste no final.

O que é: Este princípio é a materialização do conceito de "shift-left testing". Em contraposição ao modelo cascata, onde os testes são uma fase massiva no final do projeto, os testes ágeis são integrados continuamente em cada etapa do sprint.

Como funciona: As atividades de teste começam simultaneamente ao desenvolvimento. Isso inclui a participação do tester na refinamento da história para elaborar critérios de aceitação claros e testáveis, a criação de testes automatizados em paralelo ao código (como em TDD e BDD), e a execução contínua de testes ao longo de toda a iteração.

Benefício: A detecção precoce de defeitos, que se torna exponencialmente mais barata e rápida de corrigir.

B) Prevenir bugs ao invés de encontrar bugs.

Elementos Citados: Prevenir bugs, Encontrar bugs.

O que é: Uma mudança de mentalidade de controle de qualidade (QC - encontrar defeitos no produto final) para garantia da qualidade (QA - prevenir defeitos no processo).

Como funciona: O tester ágil atua como um consultor de qualidade para toda a equipe. Suas atividades preventivas incluem: facilitar sessões de exemplo de negócio (BDD) para esclarecer requisitos, promover revisões de pares de código e de casos de teste, e auxiliar na automação de testes que previnam regressões.

Benefício: A qualidade é "construída" no produto, e não "inspecionada" após o fato, resultando em um produto mais robusto e confiável.

C) Testar o entendimento ao invés de checar funcionalidades.

Elementos Citados: Testar o entendimento, Checar funcionalidades.

O que é: Vai além de verificar se o software funciona conforme a especificação técnica. Foca em validar se o software atende às necessidades reais do usuário e entrega valor de negócio.

Como funciona: Envolve uma colaboração próxima com o Product Owner e os stakeholders para entender o "porquê" por trás de cada funcionalidade. Técnicas como BDD (Behavior-Driven Development), com suas ferramentas como Cucumber e SpecFlow, usam linguagem natural para descrever o comportamento esperado, assegurando que todos (negócio e TI) tenham o mesmo entendimento.

Benefício: Entrega da funcionalidade correta que realmente resolve o problema do usuário, evitando o "foi feito conforme especificado, mas não era isso que eu queria".

D) Construir o melhor sistema ao invés de quebrar o sistema.

Elementos Citados: Construir o melhor sistema, Quebrar o sistema.

O que é: Uma redefinição do papel do tester. O estereótipo do tester como um "caçador de bugs" que se diverte em quebrar o código dá lugar ao de um "facilitador de qualidade" que é parte integrante da equipe de construção.

Como funciona: O tester ágil é um parceiro colaborativo dos desenvolvedores, compartilhando insights sobre possíveis pontos de falha e usuabilidade desde o início. O objetivo não é provar que o software está cheio de erros, mas sim ajudar a equipe a construir o melhor produto possível.

Benefício: Melhora a dinâmica da equipe, elimina a sensação de "adoversário" entre desenvolvimento e teste, e foca a energia na melhoria contínua do produto.

E) Os Testers são responsáveis pela qualidade. (A Alternativa Incorreta)

Elementos Citados: Testers, Responsabilidade pela qualidade.

Por que é incorreto: Esta afirmação é um resquício do pensamento tradicional e é a antítese do princípio ágil de equipe multifuncional e colaborativa.

A Visão Ágil Correta: Na agilidade, a qualidade é uma responsabilidade compartilhada por todos os membros da equipe.

O Product Owner é responsável por definir histórias claras e critérios de aceitação testáveis.

Os Desenvolvedores são responsáveis por escrever código limpo, realizar testes unitários e de integração, e aplicar práticas como TDD.

Os Testers (ou Engenheiros de Qualidade) são especialistas que facilitam e habilitam a equipe a atingir um alto nível de qualidade. Eles criam frameworks de automação, elaboram estratégias de teste e exploram o sistema para encontrar lacunas que testes automatizados possam não cobrir. Eles não são os únicos "donos" da qualidade.

Conclusão

Adotar os testes ágeis vai muito além de automatizar testes em sprints curtos. É uma transformação cultural que redefine o papel do tester, integra a qualidade em cada etapa do processo e, mais importante, espalha a responsabilidade pela qualidade por toda a equipe, criando um produto final superior e um processo de desenvolvimento muito mais eficiente e colaborativo.

Questão testes de sistema

Assinale a alternativa que apresenta SOMENTE tipos de testes de sistema.

A) Teste de desempenho e teste de integração.

B) Teste de segurança e teste de unidade.

C) Teste de recuperação e teste de segurança.

D) Teste de integração e teste de recuperação.

E) Teste de desempenho e teste de unidade.

Teste de sistema: é um nível de teste caixa preta, onde se avalia o sistema como um todo em relação a requisitos funcionais e não funcionais.
Exemplos de tipos de teste de sistema:
- Teste de desempenho
- Teste de recuperação
- Teste de segurança
- Teste de usabilidade
- Teste de compatibilidade
Não são testes de sistema:
- Teste de unidade (ou componente) → nível mais baixo, foca no código.
- Teste de integração → nível intermediário, foca na interação entre componentes.

Alternativas

A) Teste de desempenho e teste de integração.
Errada → desempenho é de sistema , mas integração não é.

B) Teste de segurança e teste de unidade.
Errada → segurança é de sistema , mas unidade não é.

C) Teste de recuperação e teste de segurança.
Correta → ambos são testes de sistema.

D) Teste de integração e teste de recuperação.
Errada → recuperação é de sistema, mas integração não é.

E) Teste de desempenho e teste de unidade.
Errada → desempenho é de sistema, mas unidade não é.

Resposta correta: C) Teste de recuperação e teste de segurança.

🎯 Conclusão

Esse simulado abordou temas centrais de Segurança da Informação, Testes de Software, Modelo V, OWASP, Análise de Riscos e Programação em C — todos cruciais para o cargo de Analista em Computação PROCERGS 2025.

O entendimento profundo dos princípios dos testes ágeis, dos diferentes níveis de teste (componente, integração) e dos artefatos envolvidos em cada fase é essencial para profissionais de qualidade de software modernos. A mudança de mentalidade de "testadores como guardiões da qualidade" para "qualidade como responsabilidade coletiva" representa um dos pilares mais importantes da transformação ágil bem-sucedida.

Dominar esses conceitos não apenas ajuda a responder questões técnicas, mas principalmente a implementar processos de teste mais eficientes, que agreguem valor real ao ciclo de desenvolvimento de software.

Palavras-chave: testes ágeis, teste de componente, teste de integração, qualidade de software, desenvolvimento ágil, isolamento de defeitos, responsabilidade compartilhada de qualidade.